home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc913 < prev    next >
Text File  |  1995-07-25  |  21KB  |  856 lines
  1.  
  2.  
  3. Network Working Group                                     Mark K. Lottor
  4. Request for Comments: 913                                            MIT
  5.                                                           September 1984
  6.  
  7.                      Simple File Transfer Protocol
  8.  
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    This RFC suggests a proposed protocol for the ARPA-Internet
  13.    community, and requests discussion and suggestions for improvements.
  14.    Distribution of this memo is unlimited.
  15.  
  16. INTRODUCTION
  17.  
  18.    SFTP is a simple file transfer protocol.  It fills the need of people
  19.    wanting a protocol that is more useful than TFTP but easier to
  20.    implement (and less powerful) than FTP.  SFTP supports user access
  21.    control, file transfers, directory listing, directory changing, file
  22.    renaming and deleting.
  23.  
  24.    SFTP can be implemented with any reliable 8-bit byte stream oriented
  25.    protocol, this document describes its TCP specification.  SFTP uses
  26.    only one TCP connection; whereas TFTP implements a connection over
  27.    UDP, and FTP uses two TCP connections (one using the TELNET
  28.    protocol).
  29.  
  30. THE PROTOCOL
  31.  
  32.    SFTP is used by opening a TCP connection to the remote hosts' SFTP
  33.    port (115 decimal).  You then send SFTP commands and wait for
  34.    replies.  SFTP commands sent to the remote server are always 4 ASCII
  35.    letters (of any case) followed by a space, the argument(s), and a
  36.    <NULL>.  The argument can sometimes be null in which case the command
  37.    is just 4 characters followed by <NULL>.  Replies from the server are
  38.    always a response character followed immediately by an ASCII message
  39.    string terminated by a <NULL>.  A reply can also be just a response
  40.    character and a <NULL>.
  41.  
  42.       <command> : = <cmd> [<SPACE> <args>] <NULL>
  43.  
  44.       <cmd> : =  USER ! ACCT ! PASS ! TYPE ! LIST ! CDIR
  45.                  KILL ! NAME ! DONE ! RETR ! STOR
  46.  
  47.       <response> : = <response-code> [<message>] <NULL>
  48.  
  49.       <response-code> : =  + | - |   | !
  50.  
  51.       <message> can contain <CRLF>
  52.  
  53.    Commands that can be sent to the server are listed below.  The server
  54.  
  55.  
  56. Lottor                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 913                                                   September 1984
  61. Simple File Transfer Protocol
  62.  
  63.  
  64.    replies to each command with one of the possible response codes
  65.    listed under each message.  Along with the response, the server
  66.    should optionally return a message explaining the error in more
  67.    detail.  Example message texts are listed but do not have to be
  68.    followed.  All characters used in messages are ASCII 7-bit with the
  69.    high-order bit zero, in an 8 bit field.
  70.  
  71.    The response codes and their meanings:
  72.  
  73.       +  Success.
  74.  
  75.       -  Error.
  76.  
  77.          An error occurred while processing your command.
  78.  
  79.          Number.
  80.  
  81.          The number-sign is followed immediately by ASCII digits
  82.          representing a decimal number.
  83.  
  84.       !  Logged in.
  85.  
  86.          You have sent enough information to be able to log yourself in.
  87.          This is also used to mean you have sent enough information to
  88.          connect to a directory.
  89.  
  90.    To use SFTP you first open a connection to the remote SFTP server.
  91.    The server replies by sending either a positive or negative greeting,
  92.    such as:
  93.  
  94.       +MIT-XX SFTP Service
  95.  
  96.          (the first word should be the host name)
  97.  
  98.       -MIT-XX Out to Lunch
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Lottor                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 913                                                   September 1984
  118. Simple File Transfer Protocol
  119.  
  120.  
  121.    If the server send back a '-' response it will also close the
  122.    connection, otherwise you must now send a USER command.
  123.  
  124.       USER user-id
  125.  
  126.          Your userid on the remote system.
  127.  
  128.          The reply to this command will be one of:
  129.  
  130.             !<user-id> logged in
  131.  
  132.                Meaning you don't need an account or password or you
  133.                specified a user-id not needing them.
  134.  
  135.             +User-id valid, send account and password
  136.  
  137.             -Invalid user-id, try again
  138.  
  139.          If the remote system does not have user-id's then you should
  140.          send an identification such as your personal name or host name
  141.          as the argument, and the remote system would reply with '+'.
  142.  
  143.       ACCT account
  144.  
  145.          The account you want to use (usually used for billing) on the
  146.          remote system.
  147.  
  148.          Valid replies are:
  149.  
  150.             ! Account valid, logged-in
  151.  
  152.                Account was ok or not needed. Skip the password.
  153.  
  154.             +Account valid, send password
  155.  
  156.                Account ok or not needed. Send your password next.
  157.  
  158.             -Invalid account, try again
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Lottor                                                          [Page 3]
  171.  
  172.  
  173.  
  174. RFC 913                                                   September 1984
  175. Simple File Transfer Protocol
  176.  
  177.  
  178.       PASS password
  179.  
  180.          Your password on the remote system.
  181.  
  182.          Valid replies are:
  183.  
  184.             ! Logged in
  185.  
  186.                Password is ok and you can begin file transfers.
  187.  
  188.             +Send account
  189.  
  190.                Password ok but you haven't specified the account.
  191.  
  192.             -Wrong password, try again
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Lottor                                                          [Page 4]
  228.  
  229.  
  230.  
  231. RFC 913                                                   September 1984
  232. Simple File Transfer Protocol
  233.  
  234.  
  235.    You cannot specify any of the following commands until you receive a
  236.    '!' response from the remote system.
  237.  
  238.       TYPE { A | B | C }
  239.  
  240.          The mapping of the stored file to the transmission byte stream
  241.          is controlled by the type.  The default is binary if the type
  242.          is not specified.
  243.  
  244.          A - ASCII
  245.  
  246.             The ASCII bytes are taken from the file in the source
  247.             system, transmitted over the connection, and stored in the
  248.             file in the destination system.
  249.  
  250.             The data is the 7-bit ASCII codes, transmitted in the
  251.             low-order 7 bits of 8-bit bytes.  The high-order bit of the
  252.             transmission byte must be zero, and need not be stored in
  253.             the file.
  254.  
  255.             The data is "NETASCII" and is to follow the same rules as
  256.             data sent on Telnet connections.  The key requirement here
  257.             is that the local end of line is to be converted to the pair
  258.             of ASCII characters CR and LF when transmitted on the
  259.             connection.
  260.  
  261.             For example, TOPS-20 machines have 36-bit words.  On TOPS-20
  262.             machines, The standard way of labeling the bits is 0 through
  263.             35 from high-order to low-order.  On TOPS-20 the normal way
  264.             of storing ASCII data is to use 5 7-bit bytes per word.  In
  265.             ASCII mode, the bytes transmitted would be [0-6], [7-13],
  266.             [14-20], [21-27], [28-34], (bit 35 would not be
  267.             transmitted), each of these 7-bit quantities would be
  268.             transmitted as the low-order 7 bits of an 8-bit byte (with
  269.             the high-order bit zero).
  270.  
  271.             For example, one disk page of a TOPS-20 file is 512 36-bit
  272.             words.  But using only 35 bits per word for 7-bit bytes, a
  273.             page is 17920 bits or 2560 bytes.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Lottor                                                          [Page 5]
  285.  
  286.  
  287.  
  288. RFC 913                                                   September 1984
  289. Simple File Transfer Protocol
  290.  
  291.  
  292.          B - BINARY
  293.  
  294.             The 8-bit bytes are taken from the file in the source
  295.             system, transmitted over the connection, and stored in the
  296.             file in the destination system.
  297.  
  298.             The data is in 8-bit units.  In systems with word sizes
  299.             which are not a multiple of 8, some bits of the word will
  300.             not be transmitted.
  301.  
  302.             For example, TOPS-20 machines have 36-bit words.  In binary
  303.             mode, the bytes transmitted would be [0-7], [8-15], [16-23],
  304.             [24-31], (bits 32-35 would not be transmitted).
  305.  
  306.             For example, one disk page of a TOPS-20 file is 512 36-bit
  307.             words.  But using only 32 bits per word for 8-bit bytes, a
  308.             page is 16384 bits or 2048 bytes.
  309.  
  310.          C - CONTINUOUS
  311.  
  312.             The bits are taken from the file in the source system
  313.             continuously, ignoring word boundaries, and sent over the
  314.             connection packed into 8-bit bytes.  The destination system
  315.             stores the bits received into the file continuously,
  316.             ignoring word boundaries.
  317.  
  318.             For systems on machines with a word size that is a multiple
  319.             of 8 bits, the implementation of binary and continuous modes
  320.             should be identical.
  321.  
  322.             For example, TOPS-20 machines have 36-bit words.  In
  323.             continuous mode, the bytes transmitted would be [first word,
  324.             bits 0-7], [first word, bits 8-15], [first word, bits
  325.             16-23], [first word, bits 24-31], [first word, bits 32-35 +
  326.             second word, bits 0-3], [second word, bits 4-11], [second
  327.             word, bits 12-19], [second word, bits 20-27], [second word,
  328.             bits 28-35], then the pattern repeats.
  329.  
  330.             For example, one disk page of a TOPS-20 file is 512 36-bit
  331.             words.  This is 18432 bits or 2304 8-bit bytes.
  332.  
  333.          Replies are:
  334.  
  335.             +Using { Ascii | Binary | Continuous } mode
  336.  
  337.             -Type not valid
  338.  
  339.  
  340.  
  341. Lottor                                                          [Page 6]
  342.  
  343.  
  344.  
  345. RFC 913                                                   September 1984
  346. Simple File Transfer Protocol
  347.  
  348.  
  349.       LIST { F | V } directory-path
  350.  
  351.          A null directory-path will return the current connected
  352.          directory listing.
  353.  
  354.          F specifies a standard formatted directory listing.
  355.  
  356.             An error reply should be a '-' followed by the error message
  357.             from the remote systems directory command.  A directory
  358.             listing is a '+' followed immediately by the current
  359.             directory path specification and a <CRLF>.  Following the
  360.             directory path is a single line for each file in the
  361.             directory.  Each line is just the file name followed by
  362.             <CRLF>.  The listing is terminated with a <NULL> after the
  363.             last <CRLF>.
  364.  
  365.          V specifies a verbose directory listing.
  366.  
  367.             An error returns '-' as above.  A verbose directory listing
  368.             is a '+' followed immediately by the current directory path
  369.             specification and a <CRLF>.  It is then followed by one line
  370.             per file in the directory (a line ending in <CRLF>).  The
  371.             line returned for each file can be of any format.  Possible
  372.             information to return would be the file name, size,
  373.             protection, last write date, and name of last writer.
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Lottor                                                          [Page 7]
  399.  
  400.  
  401.  
  402. RFC 913                                                   September 1984
  403. Simple File Transfer Protocol
  404.  
  405.  
  406.       CDIR new-directory
  407.  
  408.          This will change the current working directory on the remote
  409.          host to the argument passed.
  410.  
  411.          Replies are:
  412.  
  413.             !Changed working dir to <new-directory>
  414.  
  415.             -Can't connect to directory because: (reason)
  416.  
  417.             +directory ok, send account/password
  418.  
  419.          If the server replies with '+' you should then send an ACCT or
  420.          PASS command.  The server will wait for ACCT or PASS commands
  421.          until it returns a '-' or '!' response.
  422.  
  423.             Replies to ACCT could be:
  424.  
  425.                !Changed working dir to <new-directory>
  426.  
  427.                +account ok, send password
  428.  
  429.                -invalid account
  430.  
  431.             Replies to PASS could be:
  432.  
  433.                !Changed working dir to <new-directory>
  434.  
  435.                +password ok, send account
  436.  
  437.                -invalid password
  438.  
  439.       KILL file-spec
  440.  
  441.          This will delete the file from the remote system.
  442.  
  443.          Replies are:
  444.  
  445.             +<file-spec> deleted
  446.  
  447.             -Not deleted because (reason)
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Lottor                                                          [Page 8]
  456.  
  457.  
  458.  
  459. RFC 913                                                   September 1984
  460. Simple File Transfer Protocol
  461.  
  462.  
  463.       NAME old-file-spec
  464.  
  465.          Renames the old-file-spec to be new-file-spec on the remote
  466.          system.
  467.  
  468.          Replies:
  469.  
  470.             +File exists
  471.  
  472.             -Can't find <old-file-spec>
  473.  
  474.                NAME command is aborted, don't send TOBE.
  475.  
  476.          If you receive a '+' you then send:
  477.  
  478.             TOBE new-file-spec
  479.  
  480.          The server replies with:
  481.  
  482.             +<old-file-spec> renamed to <new-file-spec>
  483.  
  484.             -File wasn't renamed because (reason)
  485.  
  486.       DONE
  487.  
  488.          Tells the remote system you are done.
  489.  
  490.          The remote system replies:
  491.  
  492.             +(the message may be charge/accounting info)
  493.  
  494.          and then both systems close the connection.
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Lottor                                                          [Page 9]
  513.  
  514.  
  515.  
  516. RFC 913                                                   September 1984
  517. Simple File Transfer Protocol
  518.  
  519.  
  520.       RETR file-spec
  521.  
  522.          Requests that the remote system send the specified file.
  523.  
  524.          Receiving a '-' from the server should abort the RETR command
  525.          and the server will wait for another command.
  526.  
  527.          The reply from the remote system is:
  528.  
  529.              <number-of-bytes-that-will-be-sent> (as ascii digits)
  530.  
  531.             -File doesn't exist
  532.  
  533.          You then reply to the remote system with:
  534.  
  535.             SEND (ok, waiting for file)
  536.  
  537.                The file is then sent as a stream of exactly the number
  538.                of 8-bit bytes specified.  When all bytes are received
  539.                control passes back to you (the remote system is waiting
  540.                for the next command).  If you don't receive a byte
  541.                within a reasonable amount of time you should abort the
  542.                file transfer by closing the connection.
  543.  
  544.             STOP (You don't have enough space to store file)
  545.  
  546.                Replies could be:
  547.  
  548.                   +ok, RETR aborted
  549.  
  550.          You are then ready to send another command to the remote host.
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Lottor                                                         [Page 10]
  570.  
  571.  
  572.  
  573. RFC 913                                                   September 1984
  574. Simple File Transfer Protocol
  575.  
  576.  
  577.       STOR { NEW | OLD | APP } file-spec
  578.  
  579.          Tells the remote system to receive the following file and save
  580.          it under that name.
  581.  
  582.          Receiving a '-' should abort the STOR command sequence and the
  583.          server should wait for the next command.
  584.  
  585.          NEW specifies it should create a new generation of the file and
  586.          not delete the existing one.
  587.  
  588.             Replies could be:
  589.  
  590.                +File exists, will create new generation of file
  591.  
  592.                +File does not exist, will create new file
  593.  
  594.                -File exists, but system doesn't support generations
  595.  
  596.          OLD specifies it should write over the existing file, if any,
  597.          or else create a new file with the specified name.
  598.  
  599.             Replies could be:
  600.  
  601.                +Will write over old file
  602.  
  603.                +Will create new file
  604.  
  605.                (OLD should always return a '+')
  606.  
  607.          APP specifies that what you send should be appended to the file
  608.          on the remote site.  If the file doesn't exist it will be
  609.          created.
  610.  
  611.             Replies could be:
  612.  
  613.                +Will append to file
  614.  
  615.                +Will create file
  616.  
  617.                (APP should always return a '+')
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Lottor                                                         [Page 11]
  627.  
  628.  
  629.  
  630. RFC 913                                                   September 1984
  631. Simple File Transfer Protocol
  632.  
  633.  
  634.          You then send:
  635.  
  636.             SIZE <number-of-bytes-in-file> (as ASCII digits)
  637.  
  638.                where number-of-bytes-in-file
  639.  
  640.                   is the exact number of 8-bit bytes you will be
  641.                   sending.
  642.  
  643.          The remote system replies:
  644.  
  645.             +ok, waiting for file
  646.  
  647.                You then send the file as exactly the number of bytes
  648.                specified above.
  649.  
  650.                When you are done the remote system should reply:
  651.  
  652.                   +Saved <file-spec>
  653.  
  654.                   -Couldn't save because (reason)
  655.  
  656.             -Not enough room, don't send it
  657.  
  658.                This aborts the STOR sequence, the server is waiting for
  659.                your next command.
  660.  
  661.          You are then ready to send another command to the remote host.
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Lottor                                                         [Page 12]
  684.  
  685.  
  686.  
  687. RFC 913                                                   September 1984
  688. Simple File Transfer Protocol
  689.  
  690.  
  691. AN EXAMPLE
  692.  
  693.    An example file transfer.  'S' is the sender, the user process.  'R'
  694.    is the reply from the remote server.  Remember all server replies are
  695.    terminated with <NULL>.  If the reply is more than one line each line
  696.    ends with a <CRLF>.
  697.  
  698.       R: (listening for connection)
  699.       S: (opens connection to R)
  700.       R: +MIT-XX SFTP Service
  701.       S: USER MKL
  702.       R: +MKL ok, send password
  703.       S: PASS foo
  704.       R: ! MKL logged in
  705.       S: LIST F PS: <MKL>
  706.       R: +PS: <MKL>
  707.          Small.File
  708.          Large.File
  709.       S: LIST V
  710.       R: +PS: <MKL>
  711.          Small.File  1        69(7)  P775240  2-Aug-84 20:08  MKL
  712.          Large.File  100  255999(8)  P770000  9-Dec-84 06:04  MKL
  713.       S: RETR SMALL.FILE
  714.       R:  69
  715.       S: SEND
  716.       R: This is a small file, the file is sent without
  717.          a terminating null.
  718.       S: DONE
  719.       R: +MIT-XX closing connection
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740. Lottor                                                         [Page 13]
  741.  
  742.  
  743.  
  744. RFC 913                                                   September 1984
  745. Simple File Transfer Protocol
  746.  
  747.  
  748. EDITORS NOTE
  749.  
  750.    Mark Lotter receives full credit for all the good ideas in this memo.
  751.    As RFC editor, i have made an number of format changes, a few wording
  752.    changes, and one or two technical changes (mostly in the TYPEs).  I
  753.    accept full responsibility for any flaws i may have introduced.
  754.  
  755.    A draft form of this memo was circulated for comments.  I will
  756.    attempt to list the issues raised and summarize the pros and cons,
  757.    and resolution for each.
  758.  
  759.       ASCII Commands vs Binary Operation Codes
  760.  
  761.          The ASCII command style is easier to debug, the extra
  762.          programming cost in minimal, the extra transmission cost is
  763.          trivial.
  764.  
  765.          Binary operation codes are more efficient, and a few days of
  766.          debugging should not out weigh years of use.
  767.  
  768.          Resolution:  I have kept the ASCII Commands.
  769.  
  770.       Additional Modes
  771.  
  772.          Pro:  For some machines you can't send all the bits in a word
  773.          using this protocol.  There should be some additional mode to
  774.          allow it.
  775.  
  776.          Con:  Forget it, this is supposed to be SIMPLE file transfer.
  777.          If you need those complex modes use real FTP.
  778.  
  779.          Resolution:  I have added the Continuous mode.
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797. Lottor                                                         [Page 14]
  798.  
  799.  
  800.  
  801. RFC 913                                                   September 1984
  802. Simple File Transfer Protocol
  803.  
  804.  
  805.       CRLF Conversion
  806.  
  807.          Pro:  In ASCII type, convert the local end of line indicator to
  808.          CRLF on the way out of the host and onto the network.
  809.  
  810.          Con:  If you require that you have to look at the bytes as you
  811.          send them, otherwise you can just send them.  Most of the time
  812.          both sides will have the same end of line convention anyway.
  813.          If someone needs a conversion it can be done with a TECO macro
  814.          separately.
  815.  
  816.          Resolution:  I have required CRLF conversion in ASCII type.  If
  817.          you have the same kind of machines and the same end of line
  818.          convention you can avoid the extra cost of conversion by using
  819.          the binary or continuous type.
  820.  
  821.       TCP Urgent
  822.  
  823.          Pro:  Use TCP Urgent to abort a transfer, instead of aborting
  824.          the connection.  Then one could retry the file, or try a
  825.          different file without having to login again.
  826.  
  827.          Con:  That would couple SFTP to TCP too much.  SFTP is supposed
  828.          to be able to be work over any reliable 8-bit data stream.
  829.  
  830.          Resolution:  I have not made use of TCP Urgent.
  831.  
  832.       Random Access
  833.  
  834.          Pro:  Wouldn't it be nice if (WIBNIF) SFTP had a way of
  835.          accessing parts of a file?
  836.  
  837.          Con:  Forget it, this is supposed to be SIMPLE file transfer.
  838.          If you need random access use real FTP (oops, real FTP doesn't
  839.          have random access either -- invent another protocol?).
  840.  
  841.          Resolution:  I have not made any provision for Random Access.
  842.  
  843.    -- jon postel.
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854. Lottor                                                         [Page 15]
  855.  
  856.